Introduction to Repeaters, 
the RIC™ and LERIC™ and 
Their Applications 



INTRODUCTION 

The completion of the IEEE 802.3 10BASE-T Ethernet stan- 
dard has introduced the need for new products in the LAN 
marketplace, the twisted pair multi-port repeater. The re- 
peater, functioning as a centralized wiring hub for the 
10BASE-T star topology, is experiencing a wide variety of 
requirements as the number of 10BASE-T users increases. 
(Note: In this document the terms Hub, Concentrator, and 
Repeater are used interchangeably.) Some want a simple, 
low cost repeater that can be used in a small office environ- 
ment. Other's, foreseeing a need for expansion, need a re- 
peater that can grow with their requirements. Large compa- 
nies with hundreds of nodes need a large, expandable re- 
peater incorporating features MIS administrators can use to 
control a complex, enterprise wide network. With the grow- 
ing need for controlling and maintaining large networks, end 
users are also wanting 1 0BASE-T repeaters that offer both 
basic and sophisticated management capabilities. 
The LERIC and RIC repeater chips from National Semicon- 
ductor provide functions to meet a large variety of require- 
ments for the repeater marketplace. Not only do these de- 
vices have the necessary features for implementing differ- 
ent management capabilities, but they also have many other 
important features that allow them to be effectively used in 
a wide variety of repeater architectures, from personal com- 
puter adapter cards to huge rack mounted systems contain- 
ing hundreds of ports. 
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The LERIC, or LitE Repeater Interface Controller, is target- 
ed at the smaller, cost sensitive applications, where basic 
management or no management at all is the only require- 
ment. The LERIC can connect to 6 twisted pair segments 
and 1 thick or thin coax segment through its integrated 
1 0BASE-T transceivers and AUI port. Statistics can be gath- 
ered from internal registers or from LEDs. It also has a sim- 
ple bus for cascading many LERICs together. 
The RIC on the other hand is for networks requiring full 
network management, from small or medium size networks 
expecting to expand and for the larger, corporate wide net- 
works containing hundreds of ports. The RIC has twelve 
integrated twisted pair transceivers, an AUI port, and a cas- 
cading bus similar to the LERIC. It also has a management 
bus for easily obtaining the network statistics that are need- 
ed by high end network management software. 
The purpose of this application note is to explain and define 
the use of 10BASE-T Ethernet repeaters incorporating the 
LERIC and RIC. The following subjects will be addressed in 
this application note: 

• The role of the repeater 

• Network management fundamentals 

• Types of repeaters 

• Basic repeater functions 

• The LERIC and RIC architectures and their uses 
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FIGURE 1. Different Types of Repeaters and Hubs 



TL/F/11493-1 



Inter-LERICTM, Inter-Ric™, LERICtm, rictm, and SONICtm are trademarks of National Semiconductor Corporation. 
Veioro® is a registered trademarl< of Veioro USA, Inc. 



o 
a 

c 
o 



o 

JO 
(D 

■o 

(D 

Q> 

(D 
(0 



(D 

o 

Q> 

3 

a 

r- 
m 

O 

fi> 

3 

a 

H 

2. 

> 

■o 
■o 

o 

Q> 

o 

3 
0) 



00 
CO 



©1995 Nalional Semiconductor Corporation TL/F/11493 



RRD-B30M75/Printed in U. S. A. 



THE ROLE OF THE REPEATER 

The need for the multi-port repeater stems from the IEEE 
802.3 architecture and standards. The 10BASE2 and 
10BASE5 standards specify a coaxial cable media connect- 
ed to a bus topology. 10BASE2 has a 185 meter cabling 
limit and 30 node limit per segment. 10BASE5 has a 500 
meter length limit and 100 node maximum per segment. 
When the network requires longer distances or increased 
numbers of nodes, a repeater is necessary. While coax 
based Ethernet requires the repeater to be used to extend 
the maximum cable length, 10BASE-T twisted pair cabling 
requires the repeater to act as the central hub to implement 
its star, point-to-point topology. While it does serve to en- 
large a network, its primary responsibility for 10BASE-T 
nodes is to allow them to access other nodes on the net- 
work. (Note: A single repeater connection is referred to as a 
port, i.e., a 12 port repeater can attach up to 12 cable seg- 
ments.) 

Figure 1 (on first page of this note) illustrates several re- 
peaters used to expand and configure a network. There are 
four repeaters in this figure, each different, and each provid- 
ing an example of types of repeaters most of which are 
described later in this paper. At the top there is a simple two 
port Coax Repeater; on the left is a modular (expandable) 
repeater for large networks; on the right is a server config- 
ured with a PC Hub Card converting a typical file server into 
a combined server-repeater (sometimes called a "Serpeat- 
er"); and finally in the center is a simple small repeater for a 
small work group. Each of these example repeaters has a 
port to connect to the coax cable which is used in this ex- 
ample as a network backbone. 

Since 10BASE-T is a star topology, the repeater becomes 
the network center, and each port of the repeater connects 
to a single individual node. While the 10BASE-T network 
requires the repeater function, increasing the materials cost 
over the standard coaxial cable implementation, the above 
features offer many advantages over 10BASE5 and 
10BASE2 cabling. These reasons for the growing popularity 
of this form of Ethernet are: 

• Utilizes existing data grade twisted pair cabling similar 
wiring scheme to phone wiring. 

• Ethernet can be transmitted over low cost, standard tele- 
phone wire. 

• Point-to-point wiring eases cable installation. 

• Distributed star has a central hub for ease of network 
expansion. 

• Topology and media type results in low installation costs. 

• The hub enables centralized network management and 
centralized point for connection to other communications 
technologies. 

While MIS is interested in the financial costs of owning the 
network, they also want more control over their networks to 
maximize up-time and minimize support costs. Network 
management provides this. Since network management is 
so important, what exactly is it? 



NETWORK MANAGEMENT FUNDAMENTALS 

Network Management is the process of monitoring and con- 
trolling various parameters to give administrators greater 
control over the networks they manage. There are 5 princi- 
ple tasks and benefits of Network Management: 



Types of Management 


Task 




Benefit 


Fault 
Management 


- 


Prevents network 
downtime 


Configuration 
Management 


- 


Smoothes moves 
and changes 


Performance 
Management 


- 


Makes effective use 
of network capacity 


Accounting 
Management 


- 


Tracing network 
utilization 


Security 
Management 


- 


Protects assets 
and resources 



Management gives the network administrator a wide variety 
of significant, practical, and cost saving capabilities. For ex- 
ample, with fault management, a defective or non-compliant 
node can be partitioned off the network to prevent consum- 
ing up valuable bandwidth, without degrading the network. 
Performance management helps determine when, where, 
and what type bridge or router to install to optimize perform- 
ance on a particular segment. Charging a department for 
excessive network utilization could be done with accounting 
management. 

The 10BASE-T Ethernet topology is ideal for implementing 
network management. Because only one twisted node is 
attached to a port. In this point-to-point star topology, net- 
work statistics can now be collected in the repeater be- 
cause each node is mapped to a particular port. The port 
can be individually isolated or partitioned from the rest of 
the network if it is defective. 

It is this simple architectural feature that has compelled 
IEEE 802.3 Hub Management standards to solidify. These 
standards enable vendors to have a common reference 
point and give buyers the flexibility and assurances for hard- 
ware and software interoperability. These important benefits 
all rely on the hub as the central component of data trans- 
mission, expandability and manageability. It should be noted 
that ALL network components (Bridges, Routers, Servers, 
and Nodes) can contain some form of network management 
or some mechanism to make the control, maintenance and 
support of each device easier. It is also ideal if all network 
components could "talk" the same management language 
to simplify the monitoring of the entire network. 
Before delving into the concepts of Network Management, 
managing a network involves a number of activites, and net- 
work hardware can be designed to provide several levels of 
management for repeaters. Generally the more powerful the 
management functions the more costly the product to pur- 
chase, but the more automated network support (and 



vendors would argue) the lower the support costs. These 
levels of management provided by repeaters can be broken 
up into three basic categories: 

1. Minimal (or None): Typically no information is gathered 
by the repeater. There is no intelligence monitoring activ- 
ities. However, generally some form of LED indicators 
are provided to enable visual inspection of the repeaters 
operation. 

2. Out-Of-Band: Generally a lower cost method to gathering 
information than the In-Band. The Hub is intelligent and 
accumulates statistics. The user can only obtain these 
statistics through some visual alphanumeric display or 
more likely via a terminal attached to the hub. The major 
disadvantage of this technique is that it requires the net- 



work manager to either physically visit the Hub to deter- 
mine its operational state, or to add a modem connection 
to access remotely. This has reduced the popularity for 
this solution. 

3. In-Band: This method generally can obtain the same and 
in most cases more information about the network than 
the Out-Of-Band. The major difference is that this type of 
repeater has a node controller that can be addressed by 
a remote station over the network, and information can 
be transferred across the network. This allows the net- 
work manager to obtain the hubs information from any 
network location. 
Within each of the last two categories there is further differ- 
entiation by how much data is gathered as will be explained 
later. 
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FIGURE 2. The Network Management Model 
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To further amplify the previous concepts, it is important to 
see how a repeater fits into standard networl< management 
mechanisms. Figure 2 shows another typical network, this 
time illustrating the terms and concepts for networl< man- 
agement. This concept applies only to a network fully capa- 
ble of "In-Band" management. The terms are described be- 
low. 

The Network Management Station is a node on the network 
running network management applications software. This 
station is where the administrator can access the managed 
objects. In an enterprise LAN, network management appli- 
cation software typically is able to control network segments 
other than the one it is on. For instance, in Figure 2 the 
network manager software can be a node on one network 
segment while the managed entities are on another network 
segment (such as a PC on the right side of Figure 2). 
Jhe Agent is a network resource which receives commands 
from the manager to perform management operations and 
also reports status back to the manager. The agent is a 
separate piece of embedded software resident in the man- 
aged hub (or other device). This software communicates 
with the manager software via the network itself (in the case 
of In-Band management). Currently, standard protocols ex- 
ist that enable Manager-Agent communication across multi- 
vendor environments. Ideally a standard protocol would al- 
low a 10BASE-T hub agent from one manufacturer to com- 
municate with the manager from another. SNMP (Simple 
Network IVIanagement Protocol) is one of these. IVIanage- 
ment application software from major manufactures use 
these protocols as the lower transport layer. For instance, 
Novell's Hub Management Interface (HMI) and Hewlett 
Packard's Openview use SNMP to communicate with their 
agents. In Figure 2 the hub on the left and the Gateway on 
the right are shown to have agent software embedded in 
them. However, it is likely that the nodes would be running 
some agent software. 

The entities being managed are called the Objects. Objects 
are various network statistics that are monitored and con- 
trolled by the network manager. Objects gathered by the 
agents depend on the type of network device (i.e.. Node, 
Gateway, etc.). For Hubs and repeaters, objects include hub 
status, number of ports per hub, CRC Errors, FAE errors, 
number of good packets, etc. A defined set of objects are 
called a Management Information Base, or MIB. (Again, dif- 
ferent pieces of network equipment can gather information 
for different objects, and hence support a different MIB.) For 
Ethernet repeaters objects are defined by the IEEE 802.3 
Committee. The IEEE has standardized on the type of ob- 
jects, their attributes and a database format in which an 
agent can present the information to a manager. As stated, 
this database is called a Management Information Base, or 
MIB. The IEEE 802.3 MIB consists of 34 attributes classified 



into 3 categories called capabilities. A table detailing the 
specific objects, and how they are supported by the RIC and 
LERIC is shown at the end of this note. 
Attributes are parameters of an object that the agent col- 
lects on a per hub, group, or port basis. As described above 
for hubs, these objects include various physical layer pa- 
rameters of an Ethernet node, such a CRC errors, collisions, 
packet length, as well as more general information such as 
the hub status. Actions are those that the agent performs on 
an object at the request of the manager. As an example, an 
action could be for the agent to partition a port from the 
network or to request the source address of the last packet 
received by the hub. Notifications are unsolicited reports of 
events that may be generated by an object. An example of a 
notification would be the hub agent communicating to the 
manager if a serious hardware error occurred. 
The Basic Control objects consists of 1 9 objects which are 
mandatory, yet simple, for an agent to implement. Very little 
is required of the hardware as most of the objects are de- 
fined by the manufacturer in software. Certain key actions 
are partioning off a port and notifying the manager if a port 
is enabled or disabled or if it has been partitioned by the 
autopartition state machine. 

There are 2 Address Traclting objects that are recommend- 
ed. These objects provide the network administrator with 
information on the node addresses and changes that occur 
on a port. With the hub monitoring these, it is able to map 
each node's address to the port it's attached to and keep 
track of nodes that change port location. This could be from 
an administrator moving cables around or from a user mov- 
ing Ethernet controller boards or swapping cables. Imple- 
menting the Address Tracking category is more complex for 
the hub as the source address of all the incoming packets 
must be detected and tabulated. 

While the 13 Performance Monitoring objects are optional, 
they provide the most insight into the operation and charac- 
teristics of the network. Hubs that have this capability moni- 
tor CRC errors, collisions, PLL errors as well as many more. 
Doing this requires a lot of hardware sophistication. 
These 3 categories were chosen by the IEEE Hub Manage- 
ment Task Force to give hub manufacturers the flexibility to 
design products with 3 different price and capability levels. 
This was done to prevent hub manufacturers from being 
forced to implement all 3 categories if only a low cost Basic 
Control hub is required. It should be noted that if a hub 
agent supports one managed object in a category, then it 
must support them all to claim IEEE conformance of that 
category. For instance, if a manufacturer's hub collects the 
number of transmit collisions a port experiences but is not 
able to count the number of frame alignment errors, then 
the vendor can't claim to support the IEEE Performance 
Monitoring category. 
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FIGURE 3. Examples of Different Types of Repeaters Plotted by Number of Ports versus Features 



TYPES OF REPEATERS 

Before discussing how the RIG or LERIC is used in various 
repeater applications, it is very useful to look at the kinds of 
repeaters typically available and what they are used for. 
At its core a repeater function is a very simple concept (re- 
transmit data coming in on one port out another port). Prod- 
uct differentiation comes from the features added to the 
basic repeater function. The key differentiators are number 
of ports, maintainability (really network management capa- 
bilities), expandability, and ease of integration into a net- 
work. The first two features are the most important and form 
the axis of Figure 3. This figure breaks down the repeater 
types into 7 basic categories. In any given feature category 
other port counts than those shown are likely, however, this 
figure attempts to categorize the most popular configuration 
sizes. 

As networks grow larger they require the repeater to have 
more features, as this diagram shows. Larger installations 
require a repeater to be expandable. As the network grows 
the repeater must grow with it to minimize duplicating equip- 
ment purchases. Having proper expansion capabilities en- 
ables this. These larger installations also require standard- 
ized network management that communicates across ven- 
dor boundaries. On the other extreme are the smaller of- 
fices where low cost and ease of use are the primary issues. 
These environments experience limited growth (a small 
dentist's office for example) so expandability is not as im- 
portant either. 

In the following sections we will describe the basic functions 
and features of these 7 repeater types. 



SIMPLE STAND-ALONE HUB 

The simple stand-alone hub as shown in Figure 4 has be- 
tween 6-12 ports, doesn't have any management, and isn't 
easily expandable. This type of repeater is a fully self con- 
tained box, containing the repeater function, and power sup- 
ply. (Note the term Velcro® hub is applied because the 
small size of these hubs let you stick them almost any- 
where.) 
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FIGURE 4. Simple Stand-Alone Repeater 

The primary features of this product is its simplicity and low 
cost. This hub is simply intended for a small network where 
the users needs and understanding are simple. The user 
places a high value on a simple "plug-n-play" box. For 
maintenance and troubleshooting, this type of hub would 
have some status LED indicators, at least receive and colli- 
sion activity LEDs for each port. This facilitates simple diag- 
nostic on the network. These hubs typically provide an AUI 
(Attachment Unit Interface) port to connect to an existing 
10BASE2 or 10BASE5 Ethernet LAN. The AUI can also be 
used to cascade other repeaters boxes if needed. However, 



this method of cascading is relatively more expensive than 
using an expandable repeater because expansion is proba- 
bly through external MAUs (Media Access Units) and the 
proper cabling. Expansion can also be accomplished by 
cascading 10BASE-T Ports but this reduces the number of 
available ports by 2. 

SIMPLE EXPANDABLE HUB 

The simple expandable hub is essentially the Stand-Alone 
hub, but designed with card slots to facilitate the addition of 
more ports into the repeater chassis (as shown in Figure 5). 
This is used when a network is expected to grow but not too 
large. These hubs could support up to 24-36 nodes. The 
key feature of this type is its ability to expand very simply 
and inexpensively. These hubs typically use a proprietary 
bus to cascade 6 or 12 port repeaters together. This bus 
implementation is less costly than using coax to cascade 
repeaters. 
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FIGURE 5. An Example of a 36 Port Modular Repeater 

Like the Stand-Alone repeater this repeater usually imple- 
ments LED status indicators, but usually does not provide 
sophisticated management. In some cases an add-in card 
for out of band management (including a CPU and RS-232 
port) may be available, however most of the implementa- 
tions desiring management are trending to add in the flexi- 
bility of the Managed Modular Repeater discussed later. 

SIMPLE PC HUB CARD 

The concept of a PC add-in card that includes the function 
of a repeater is relatively new, but (due to the prevalence of 
PCs) provides a lot of features and benefits when compared 
to other options. The basic idea is to add a repeater to an 
Ethernet adapter, thus creating a card that when added to a 
PC very inexpensively turns a PC into a central control point 
for a typically small network. A PC equipped with this card 
can be used as a server-hub, or just provide a hub at less 
cost than the Stand-Alone Repeater (primarily because the 
adapter hub does not need to have a case or power supply). 
A typical example is shown in Figure 6. 
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Electronics 
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There are two major categories of repeater cards, a high 
end managed card (discussed later) and a low end simple 
card. The low end implementation typical implements 4-6 
10BASE-T ports (6 RJ45 connectors is the maximum that 
can fit through the back slot of a PC), and possibly include 
either an AUI or 10BASE2 connection. Some implementa- 
tions provide a slave repeater card (containing only the re- 
peater) that can be cascaded to the master Ethernet adapt- 
er-repeater card. This allows some expansion capability. 
In addition to low cost, the advantage of this application is 
that user friendly utilities can be written for the PC to enable 
some form of management to be implemented inexpensive- 
ly (usually just the Basic Control objects are supported). The 
major disadvantage is that if the PC is switched off then the 
network goes down. 

BASIC MANAGED REPEATER 

One might think that a basic managed repeater without ex- 
pandability would not have any application, however, there 
are two good applications for this repeater, and as costs for 
the management function drop the incremental price for 
added management functionality will become more popular. 
In one case, if the end user of a small or medium sized 
network is sophisticated enough he may desire a greater 
understanding of network health and thus need more thor- 
ough management capabilities. 

Another popular application for this repeater is in a small 
semi-isolated work group in a sizable network. The work 
group itself may not require expandability, but since this 
work group is part of a large network then it is likely that this 
hub will be maintained by a central MIS organization. This 
organization will demand consistent hub maintenance to the 
rest of the network, and will require more sophisticated 
management than for a Stand-Alone Hub. This type of re- 
peater looks much like Figure 4, but internally several com- 
ponent functions have been added. 
Extensive management capabilities include the implementa- 
tion of Performance Monitoring, Address Tracking and Ba- 
sic Control MIB object tracking capabilities. Typically a CPU 
and a network interface controller provide the management 
function. This would allow the hub to be an addressable 
node on the network and the hub could be controlled re- 
motely via the manager. This hub would require more mem- 
ory and a larger power supply. Also the communications 
protocol, SNMP for example, running on this hardware plat- 
form. Typically this hub implements the IEEE 802.3 Hub 
Management Basic Control objects. 

FULLY MANAGED PC HUB ADAPTER 

This adapter hub is conceptually similar to the low cost PC 
hub card, except that two major features are added: 1) Ex- 
tensive Management and Diagnostics are provided, and 2) 
Each card supports 12 ports by using a high density con- 
nector to get the cables out of the PC, and an additional 
breakout box to convert to 12 RJ45 connectors. 
This card's application is in high end corporate servers, and 
has been spurred by Novell's creation and promotion of HMI 
(Hub Management Interface) which provides a driver level 
mechanism to gather IEEE hub management objects. Due 
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FIGURE 6. Typical Node/Hub PC Adapter 



to the large network environment a more sophisticated re- 
peater is required as it is necessary to gather all IEEE hub 
management objects. 

A server-repeater (Serpeater?) facilitates a number of possi- 
bilities in the corporate network environment. It enables very 
centralized total network services. A single box can provide 
not only file and print services, but can also provide routing, 
bridging and repeating. This potentially can ease network 
maintenance, and simplify configuration. However, as be- 
fore the PC mechanically does not make a good repeater 
primarily due to the card slot form factor, and due to the 
limited expansion capabilities (usually it is difficult to add 
more than 48 ports to a server without using external re- 
peaters. 

FULLY MANAGED MODULAR REPEATER 

For larger networks or workgroups all levels of in band net- 
work management are required. Like the Basic Managed 
Repeater, and the Fully Managed PC Hub Adapter, Perform- 
ance Monitoring, Address Tracking and Basic Control capa- 
bilities need to be incorporated into the hub. This hub is 
shown in Figure 7. 

Larger networks, 24-60 nodes, not only require full network 
management but now expandability is a very important is- 
sue. One can think of these repeaters as being very similar 
to the Simple Expandable Hub except that a high perform- 
ance management agent is required and the expansion op- 
tions tend to be more varied to support a large multi-vendor 
network. 

MULTI-FUNCTION MODULAR COMMUNICATIONS 
RACK 

A short conceptual jump from the Fully Managed Modular 
repeater is to support other communications technologies, 
such as Token Ring, FDDI, Routers, gateways, and poten- 



tially servers. These multi-function communications equip- 
ment is for only the large networks, so extensive, computing 
power is required. Because of the level of network manage- 
ment required of these repeaters, sophisticated yet proprie- 
tary management applications software is typically offered 
by the manufacturer. This software would run over standard 
protocols however. 

BASIC RIC AND LERIC REPEATER FUNCTIONS 

The previous section focused on the feature and function 
differences of the various repeater architectures, highlight- 
ing their advantages and disadvantages. However, each 
hub contains the same basic repeater functions as defined 
by the IEEE. This is key as repeaters from many manufac- 
turers need to communicate with each other and Ethernet 
DTEs. 

This following section describes the basic repeater func- 
tions that all repeaters must have. The description is given 
by using the RIC/LERIC architecture. It is possible to imple- 
ment the repeater issuing different functional partitioning, 
however, the functions of a general repeater are basically 
the same. The block diagram of Figure 8 shows the major 
functional blocks of a RIC or LERIC based repeater that 
implements the requirements of the IEEE and upon which 
the repeater products described earlier can be built. 
It should be noticed what is not included in the repeater 
architecture. There is no complete MAC or Media Access 
Control unit. MACs are used by Ethernet controllers to im- 
plement the CSMA/CD protocol for gaining access to the 
media. Also, repeaters don't do address filtering or routing. 
These are done by gateways and bridges. Repeaters simply 
repeat the data that is received from one port and transmit it 
to all the others. The repeater has to re-time the received 
packets and remove accumulated jitter. The repeater must 
also not allow defective nodes to consume network band- 
width. 
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FIGURE 7. Typical Modular Repeater Including Options for Multiple Cable Media and Network Management 
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FIGURE 8. Simplified General Block Diagram of the Core Repeater Functions of the RIG and LERIC 



PORT SPECIFIC FUNCTIONS 

Within a repeater there are functions that are shared by all 
the ports and those that each port duplicates for itself. As 
the diagram shows, there are 5 functional blocl<s that are 
identical for each port. 

Analog Interface/Transceivers. This blocl< is not actually 
an 802.3 requirement. In a general repeater this function is 
required to connect the repeater to the media, and is gener- 
ally incorporated into the repeater box, but it is not actually 
part of the repeater standard. Most integrated repeaters im- 
plement either a transceiver interface or all or part of a 
transceiver. In the case of the RIC/LERIC, this blocl< in- 
cludes all functional and electrical specifications to interface 
to a particular transmission media (coax, twisted pair, fiber). 
It should be noted that with the exception of the transceiver, 
everything about the repeater is independent of what media 
is attached to the ports. When the transceivers are for twist- 
ed pair, they monitor the linl< integrity of the attached seg- 
ment. 

Port Logic. This block performs many different functions. 
There are two different state machines for each port. One is 
called the Port State Machine, or PSM. This state machine 
is linked with all the other PSMs to perform port arbitration. 
This arbitration is needed to determine which port should be 
the source of data or collision information when multiple 
ports receive data simultaneously. The winning port is called 

Port N or Port M depending on the type of activity. 

Port N is defined as the highest priority port experiencing 

receive or collision activity. Port M is defined as the high- 
est priority port that is last experiencing a collision. This 
state machine is also used to detect collisions and indicate 
them to the other ports. The second state machine imple- 



ments the port auto-partioning algorithm. When a port expe- 
riences more than 30 consecutive collisions, this state ma- 
chine prevents any further data on this port from being re- 
peated on the network. This effectively blocks it off. The 
port is re-enabled when a packet is successfully received or 
if a packet is transmitted to it. 

The port logic also monitors a port to determine if a trans- 
mission exceeds a specified limit, and if so turns off that port 
so it doesn't bog the network down. The port is re-enabled 
after a specified time period has elapsed since the transmis- 
sion ended. 

CENTRAL REPEATER FUNCTIONS 

All repeaters tend to have some functions common to the 
individual ports implemented as a central function. The RIG/ 
LERIC are typical implementations and implement the fol- 
lowing blocks as a central function. 
Multiplexer. This function multiplexes the packet from 

Port N to internal functions in the repeater. 

Decoder/FIFO/Encoder. The Decoder/FIFO/Encoder 
plays an important role in the recovering and re-timing the 
Ethernet data. As a signal travels from the DTE to the re- 
peater several factors degrade the quality of the signal, and 
the repeater must remove these distortions before re-trans- 
mitting the data. 

1. The signal transmitted down the Ethernet media accu- 
mulates jitter due to the different impedances, noise, and 
discontinuities in the cable. 

2. The preamble of the receiving packet is shortened. This 
caused by the signal being attenuated and delays in the 
squelch circuitry being activated. 



This block helps to eliminate these degradation. It has a 
phase lock loop which removes jitter. The packet is then 
sent to the FIFO. The FIFO buffers the data portion of a 
packet until a proper length preamble can be transmitted by 
the ports. The FIFO also compensates for data rate differ- 
ences between the node and repeater. The encoder puts 
the packet back into manchester form, but now encoded 
without jitter and at the proper frequency. 

Central State Machine and Counters. These functions 
form the heart of the repeater. They control the port logic 
and the majority of data and collision propagation opera- 
tions as defined by the IEEE specifications. This block in- 
sures minimum packet fragment length and controls the 
FIFO to insure that the preamble is of the specified length. 
Collisions are also handled here. When a port is repeating a 
packet and senses activity on its RX± pair a transmit colli- 
sion will result. The central state machine will transmit a jam 
pattern to all the ports to inform the attached nodes of a 
collision. This block also implements other IEEE defined 
timings and functions central to the repeater function. 
Display Devices and Drivers. While not required by IEEE, 
some form of status display information can provide indica- 
tion of repeater health. This block takes various signals from 
within the repeaters and makes them available to the dis- 
play. 

Cascade Logic. For a modular repeater this logic provides 
the key internal arbitration and data signals externally to 
facilitate the addition of additional repeaters/ports to the 
repeater system. 

THE LERIC AND RIC ARCHITECTURES 
AND THEIR APPLICATIONS 

The LERIC and RIC are National Semiconductor Corpora- 
tion's solution to the implementation of IEEE 802.3 compati- 
ble multi-port repeaters. The LERIC and RIC offer all the 
features needed to address this marketplace. One of the 
most important features is the ability to support network 
management. The LERIC and RIC offer different levels of 
network management. As stated at the beginning, the 
LERIC is focused toward applications in small networks 
where basic management or no management at all is re- 
quired. The RIC, on the other hand, is ideally suited for large 
networks where performance monitoring in addition to basic 
management capabilities are required. 



THE LITE REPEATER INTERFACE CONTROLLER 

The LERIC is a fully IEEE compliant repeater using as its 
core the general repeater architecture described previously. 
It adds all the features needed to be effectively used in its 
intended applications: the smaller networks where limited 
management is the only requirement. In these applications, 
Basic Control management is easily accomplished with the 
LERIC. 

The LERIC, in addition to the basic repeater blocks dis- 
cussed earlier has a number of specific feature blocks that 
are described in the following sections. 
Six Twisted Pair Transceivers and AUI Port 10BASE-T 
transceivers are integrated onto the LERIC to save board 
real estate. The transceivers meet the IEEE 802.3 
10BASE-T specifications. The transceivers can be disabled, 
and turned into pseudo-AUl ports for connection to coax or 
fiber transceivers. While not fully AUI driver level compati- 
ble, they can drive a short distance on a PCB for connection 
to these alternate transceivers. The LERIC also has a single 
fully IEEE compatible AUI port that can drive a standard 
50 meter AUI cable or can connect to a coax or fiber trans- 
ceiver directly on the PCB. This port is typically used to 
enable the LERIC to connect to a network backbone. 
CPU Bus. The LERIC has a bus so a CPU can access 
internal registers of the LERIC. One of these is a status 
register that indicates if any port is experiencing a reception, 
collision, partition, or if the LERIC is jabbering. In addition to 
the LERIC status register which indicates status for the en- 
tire repeater, each individual port has its own status register, 
called the Port Status and Configuration Register. Each port 
can be configured through this register. A port can be dis- 
abled and the squelch level be reduced to handle special 
cable conditions. 

The CPU bus is multiplexed to provide the signals to per- 
form the Mode Load self-configuration and is the pathway 
for the LED status signals as described below. 
LED Display. The LERIC provides information to driver 
LEDs through the multiplexed operation of the CPU bus. 
Low cost 74LS259 addressable latches are used externally 
to latch the CPU bus and drive the signals to the LEDs. 
The LEDs are used for visual monitoring of the repeaters 
status. There are two modes of LED display in the LERIC. In 
maximum mode, 5 LEDs are provided for each of the twist- 
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ed pair ports to indicate reception, collision, partition, polari- 
ty, and link status. The AUI port has LEDs for collision, re- 
ception, and partition status. There is also and LED to indi- 
cate jabber status of the repeater. 

Mode Load. An important feature of the LERIC is its ability 
to perform a hardware self-configuration. Simple pull-ups 
and pull-downs are attached to the CPU bus in a configura- 
tion suited for the particular application. When the mode 
load signal is asserted, the bit pattern defined by these re- 
sisters is loaded into the LERIC and it is configured. This 
operation is typically done for power-on configuration of the 
LERIC, but can also be used whenever LERIC needs to be 
reset and reconfigured. Options such as twisted pair or 
pseudo-AUl port definition, external PLL, LED display mode, 
and others are loaded here. 

Inter-LERIC Bus. The Inter-LERIC bus is used for cascad- 
ing multiple LERICs and interfacing to a network controller 
for In-Band hub applications. There is often the need to 
have more than 6 ports and/or a network controller so hav- 
ing a simple, but powerful way to expand is very important. 
The Inter-LERIC bus consists of three groups of signals: 

• Port Arbitration Signals . These signals provide a way for 

multiple LERICs to arbitrate for Port N and Port M 

status. The port arbitration signals essentially connect 
the arbitration logic of the port state machines together. 

• Status Signals. The status signals indicate receive data 
activity and collision status of the network and communi- 
cate it to the different LERICs. 



• Data Signals. These signals actually transfer the repeat- 
ed packet from the LERIC containing Port N to all the 

other LERICs and to a network controller if there is one 
in the system. Packet data from the receiving LERIC is 
decoded from manchester and put into serial NRZ form 
before being driven onto this bus. The rest of the LERICs 
read the data and encode it back into manchester before 
transmitting the data to the ports. 
There are two versions of the LERIC, and the major differ- 
ence is the implementation of the Inter-LERIC bus. On the 
DP83955, the bus is designed with fewer signals intended 
for limited cascading primarily on a signal card. The 
DP83956 has the same bus as the RIC (DP83950) and 
therefore can be easily externally buffered and cascaded 
over large buses or many cards. 

LERIC APPLICATIONS 

The LERIC fits in designs at the lower end of the Port and 
Feature spectrum of Figure 3. These applications are de- 
scribed in the following. 
Simple Stand-Alone Hub 

This design is very straightforward. In the example of Figure 
10, a 12-1-2 Hub, two LERICs are used. These two chips 
are cascaded directly through their Inter-LERIC bus. The 
media interface to twisted pair is very simple requiring only a 
few buffers, filters and transformers. The status indication 
for each port is displayed via an LED array, this array is 
connected to each LERICs CPU/LED bus, and feeds some 
74LS259's which drive the LEDs. 

This simple interconnection of 2 LERICs and minimal exter- 
nal logic enables the design of a very compact hub. 
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FIGURE 10. Simple 12 Port Twisted Pair Hub with both a Thin Cable and AUI Connection 
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Simple Expandable Hub 

This appiication buiids on top of the previous simple hub, 
and adding some buffer logic onto the Inter-LERIC bus. The 
biggest design change is really mechanical. Rather than a 
single PCB design as in the Stand-Alone Hub, this design is 
usually based on some form of card cage or plug-In slots. 
Figure 11 shows a block diagram for a 6 port module that 
could be plugged into the card cage with other similar mod- 
ules to make this a versatile setup. 
Simple PC Hub Card 

This repeater takes advantage of the PCs power supply, 
enclosure and CPU. As mentioned this architecture takes 
advantage of the PC to provide a very flexible repeater and 
adapter card combination. The DP8390 Network Interface 
Controller with its buffer RAM and bus interface provides 
the MAC to the network and buffers packets to a local mem- 
ory for later processing. This allows the card-PC to act as a 
typical network attached computer. This implementation 



also connects the LERIC's Registers to the PC bus, en- 
abling PC based software to provide basic managed ob- 
jects. 

Typically this type of design has between 4-6 RJ-45 ports. 
Six is the maximum number of RJ-45s that can be accessed 
through the standard PC's back slot opening. The AUI port 
interface shown in Figure 12, Is typically brought out a sepa- 
rate slot if needed. 

The cascade port is usually connected to other cards via a 
ribbon cable. When more ports are required, additional 
slave LERIC adapter cards can be cascaded to the main 
master card through the buffered Inter-LERIC bus (top of 
Figure 11). 

Unlike previous examples, the display Interface is typically 
very simple. Minimum mode display give some general pur- 
pose display which is typically used for installation diagnos- 
tics. (For run time diagnostics a software implementation 
can be developed to display the "LED-like" symbols on the 
PC's display.) 
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FIGURE 1 1. Module Hub with 6 Port 10BASE-T Modules 



r 



DP8390 
Ethernet 
Controller 



i. TJ (J 



^ 'i- I Buffer 

Jl^ Ram 



Minimum Mode 
Display 



^ 



T 



DP85956 

LERIC 

(LitE 

Repeater 

Interface 









*-¥ 


10BASE-T 

Filter and 

Choke 


■ ■ a 


'i ' 








o 


10BASE-T 

Filter and 

Choka 


4J-^ 








4-> 


10BASE-T 

Filter and 

Choke 












4-^ 


10BASE-T 

Filter and 

Choke 


♦{-► 








^-> 


10BASE-T 

Filter and 

Choke 












*-► 


10BASE-T 

Filter and 

Choke 


4> 









TL/F/11493-12 



FIGURE 12. Simple PC Hub Card Block Diagram 



11 



Low End In-Band Managed Hub 

There are many applications of the LERIC where it is fo- 
cused at smaller networks under 24 ports where full network 
management isn't needed. This repeater configuration sup- 
ports the Basic Control capability of an IEEE MIB. The LER- 
IC is able to turn ports on and off and indicate their status to 
a requesting manager. Address Tracking is possible, by us- 
ing the NIC in promiscuous mode. Performance Monitoring 
is not possible with the LERIC because it doesn't have the 
capability to gather all the required physical layer statistics. 
As can be seen from Figure 13 the block diagram for this 
type of hub is very similar to the PC Hub card except that a 
CPU and RAM/ROM are added, and the port restrictions of 
the PC do not apply. The internal registers of the LERIC are 
easily accessible by the host CPU so management informa- 
tion can be easily collected. 

THE REPEATER INTERFACE CONTROLLER 

The DP83950 RIC is a high end, feature rich device which 
implements all the required functions of an IEEE compatible 
repeater along with many additional features that enable it 
to gather all the mandatory, recommended, and optional 
IEEE capabilities for network management. The RIC is in- 
tended for networks requiring full network management now 
or the need for it in the future. 

To compare the RIC and LERIC, they both have a cascad- 
ing bus for expandability. In fact, the Inter-RICTu bus and 
the Inter-LERICTM bus are identical between the DP83950 
and the DP83956, and can be connected together (The 
DP83955 Inter-LERIC bus is slightly different but still com- 
patible). 

Another difference between the RIC and LERIC is that the 
RIC contains 12 transceivers verses the LERICs 6. Howev- 
er, like the LERIC these 12 RIC ports can be selected to be 
configured as either pseudo-AUl port or twisted pair. The 
RICs internal twisted pair transceivers are identical to the 
LERICs. 

Both the RIC and LERIC have the same modes of LED 
display. Like the LERIC, the RIC also can be configured with 
the Mode Load operation, but it is more likely to be config- 
ured by a CPU that typically resides in larger hub configura- 
tions. 



By far the most outstanding difference between the RIC and 
the LERIC is their level of network management statistics 
gathering capability. Because the RIC is focused at the larg- 
er networks where full management is required, it has a 
much wider array of management components. There are 
two sources of network statistics in the RIC: 

• Status, Event Record, and Event Counting registers, and 
Interrupts 

• Management bus 

Internal Registers. Like the LERIC, the RIC has status 
registers that give repeater status and individual port status. 
In fact, these registers are very similar except the RIC pro- 
vides more port status information. What makes the RIC 
different are the Event Record and Event Counting Regis- 
ters, and the two interrupt pins. Each port has one each of 
these registers and they collect the important physical layer 
statistics that are needed by the IEEE Performance Monitor- 
ing objects. 

Events in the status, Event Record and Event Counting can 
generate interrupts to the CPU through either the Real Time 
Interrupt (RTI) or the main Interrupt pin. This facilitates real 
time statistics gathering. 

The Event Counting register counts a single network event 
on its every occurrence. One of 11 events are available to 
chose from which is done by software through a mask regis- 
ter. This function is particularly useful to count a rapidly oc- 
curring event, such as collisions. When the counters reach 
one of several chosen thresholds, they can interrupt the 
CPU. 

The Event Record register is more flexible but requires more 
attention by the CPU as it provides real time status informa- 
tion. This register can be configured to log the occurrence 
of up to 8 events in a byte wide register. Not all 8 need to be 
logged and can be chosen through a mask register. Every 
time an unmasked event occurs an interrupt can be gener- 
ated. 

The other registers in the RIC allow software to quickly iso- 
late which port is the source of activity without having to poll 
each register. 
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The Management Bus. Collection of a wide variety of net- 
work statistics is a major feature of the RIC, and the man- 
agement bus is the RIC's most powerful pathway to commu- 
nicate this information to an intelligent repeater system. The 
RIC couples to an Ethernet controller to form an intelligent, 
In-Band repeater. The management bus is similar to the 
data signals of the Inter-RIC bus. What makes the manage- 
ment data signals different from the Inter-RIC bus is that per 
packet statistics associated with the currently repeated 
packet are appended to the end of the packet on the man- 
agement data signals, as shown in Figure 15. 
The information sent on the management bus is contained 
in the seven additional bytes the RIC appends to the end of 
the packet, as shown in Figure 16. 

These seven status bytes are on a serial data bus and are 
sent to main memory by adding a custom circuit, or more 
typically by a network interface controller. This can be ac- 
complished using the DP8390 NIC or the SONICtm. There 
are advantages and disadvantages to all three approaches. 
Designing a custom de-serializer circuit which converts the 
serial management data so that can be read by the host 
CPU takes design time but the interface can be tailored to 
the systems interface of the repeaters architecture. Since 
the repeater is In-Band, and Ethernet controller is still need- 
ed somewhere in the system. 

Secondly, the NIC offers a low cost solution to buffering the 
management information to memory. A somewhat faster 
CPU (than in the first or third options) may be necessary to 
ensure that the NICs buffer does not overflow due to the 
large number of packets received by the hub. 
The third solution is to connect the higher performance 
SONIC controller to the management bus. The SONIC pro- 



vides signaling to enable the use of a special feature of the 
RIC-SONIC interface which is the ability to optimize packet 
storage and bus bandwidth by eliminating the unnecessary 
data field from packets (except for management packets 
which are addressed to the SONIC where the data field 
must be retained). This feature is called Packet Compres- 
sion. 
There are several advantages to the management bus: 

• In a multi-RIC repeater, the management status bytes 
are mostly available from one source. This saves a proc- 
essor from having to read data from a multitude of sourc- 
es. 

• CPU performance requirements may be reduced since 
using the management bus for gathering of network sta- 
tistics and buffing from the CPU eliminates most of the 
real time processing required when statistics are gath- 
ered entirely by using the RIC's registers. 

• The management bus records interframe gap time which 
allows the administrator to see if there are any nodes 
that violate this important IEEE spec. 

• When using a SONIC controller, packet compression can 
be employed, and this can further reduce system over- 
head, by eliminating the buffering of packet data. The 
SONIC only has to buffer the 21 bytes (7 status -I- dest. 
address + source address + type/length field) in 6 
32-bit write operations. This can be done very quickly, 
(<1 us). 

The management bus architecture is particularly cost effec- 
tive for in band management hubs. These hubs will require 
an Ethernet controller to communicate to the Network Man- 
ager, and in this case the use of the management requires 
no addition logic to implement. 
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FIGURE 15. Signals Appearing on the Management Bus 
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RIC APPLICATIONS 

Like the LERIC, there are many applications for the RIC. 
The primary (though not only) applications for the RIC are in 
high end hub applications where full support of hub man- 
agement IEEE objects are required. The large rack mounted 
system is an ideal application for the RIC for high end re- 
peaters. 

FULLY IVIANAGED REPEATER 

For networks not quite so large but needing management, a 
fully enclosed module running SNMP with 12-24 ports im- 
plements a low cost hub yet provides all the management 
capabilities of larger systems. This is called the Fully Man- 
aged Hub. This system block diagram is very much the 
same as for the Modular Managed Hub, except that a single 
non-expandable 12-24 port PCB contains the repeater 
function, and Ethernet Controller, CPU and memory. Func- 
tionally, this system's block diagram is very similar to the 
Managed Modular Hub of Figure 17. Hence the functional 
description is the same as the modular managed repeater 
described next. 



IVIANAGED IVIODULAR REPEATER 

The modular managed repeater example is a rack mounted 
repeater, containing independent repeater modules. Since 
these repeaters could support up to hundreds of ports, it 
must be easily expandable. The modules are typically 
stacked vertically or horizontally in a chassis. Sophisticated 
In-Band network management is required and so an Ether- 
net controller with a CPU usually on a separate module is 
required. The ideal controller is the SONIC directly connect- 
ed to the RIC. Expandability is very important so the hub 
can grow along with the network. 

In Figure 17, the block diagram of the management module 
is shown on the left, and one of several repeater modules 
block diagram is shown on the right side. The backplane for 
this modular repeater is actually the center of the hub. This 
backplane usually consists of 3 buses. First, a CPU bus 
which allows the management module's CPU to control the 
repeater modules. Second, a management bus which is an 
extension of the RIC's management bus, and allows the 
management module's SONIC to access the RIC statistics 
information. Third, the repeater also has a repeater cascade 
backplane for connecting multiple repeater modules into a 
single logical repeater. 
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FIGURE 18. Block Diagram for Fully Managed PC Hub Card 



FULLY MANAGED PC ADAPTER 

This repeater application has become popular since the de- 
velopment of Novell's Hub Management Interface (HMI) 
specification. This driver specification provides a standard 
software method to obtain all the network management ca- 
pabilities of the larger, self-contained hubs, but hardware Is 
much simpler and less costly (if you assume that the cost of 
the PC is not included). The block diagram of this adapter 
card is very similar to the LERIC/NIC solution except that a 
RIC is typically used in conjuction with a higher performance 
Ethernet Controller such as a 16-bit or 32-bit SONIC, as 
shown In Figure 18. 

Since many servers are based on the EISA or Micro Chan- 
nel bus, a 32-bit SONIC could act as a high performance 
bus master. An ASIC and/or other logic provides the inter- 
face between It and the system. On the network side, the 
SONIC's PLL/ENDEC is disabled and the management bus 
connected to the receive signals and the Inter-RIC bus con- 
nected to the transmit signals using a simple PLD incorpo- 
rates some of the needed glue logic. 
12 twisted pair ports of RJ45's are physically too large to fit 
into one PC expansion slot opening. So usually the port 
connection is made via a high density 50 pin (like a SCSI II) 
connector, and a cable connects to a breakout box, contain- 
ing a 12 position RJ45 connector and typically the LED ar- 
ray. 



The breakout boxes are usually placed on the floor or in 
some sort of standard rack. Figure 19. Typical configura- 
tions support up to 48 10BASE-T nodes with an AUI port for 
attachment to a 10BASE5 or 10BASE2 network. Expansion 
limitations are primarily due to the limited PC slot configura- 
tions. 
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FIGURE 19. Breakout Boxes out of the File Server 
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FIGURE 20. Possible Modules for Communications Rack 
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FIGURE 21. Bridge/Router Combined with a Repeater (Using Hardware Address Filtering) 



Vendor's offer a lot of flexibility in server configurations by 
offering slave adapters. These adapters are repeater 
boards without the controller. This allows the creation of 
single large repeaters with a single controller, or to use mul- 
tiple controllers creating several networks connected by the 
server's bridging software. 

Using Novell's Remote Network Interface, In-Band man- 
aged hubs can be located in other nodes besides the serv- 
er. This allows repeaters to be distributed around the net- 
work where workgroups are more concentrated. Manage- 
ment can be done remotely from any node. Using this broad 
systems approach allows very large managed networks to 
be constructed at reasonable costs. 



For expansion, additional RIC slave cards can be cascaded 
to the master card through the Inter-RIC bus and manage- 
ment bus. All of the RICs in this system are configured by 
software. 

MODULAR COMMUNICATIONS RACK 
For the purposes of this document, the Communications 
Rack is really a modular multi-function box (typically placed 
on a rack in a wiring closet) that in the ideal case, can sup- 
port and LAN (or Wide Area Network) connection function. 
As shown in Figure 20 this box could support not only re- 
peater and management functions but bridge router, WAN 
connections, SNA Gateways, or possibly even file and print- 
er server functions. 
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When using the RIC in this type of equipment, the architec- 
tures are very similar to previous modular repeaters, except 
that the bus supports more sophisticated functions, proba- 
bly the rack's backplane is actually a high speed 16-bit- 
32-bit parallel data/control bus that routes network data be- 
tween modules in a very sophisticated manner. The details 
of the architectural for such a box is beyond this paper, as it 
would involve discussions beyond applying the RIC or 
LERIC. However, there are a couple of interesting appli- 
cations for the RIC within this box. 

The most interesting one is the bridge/router-hub module, 
as shown in Figure 21. In this application, which does use 
the RIC-SONIC combination yet again, utilizes the SONIC'S 
internal CAM as an address filter. In this application a single 
RIC connects point-to-point to the RIC. Since only 12 nodes 
would typically be connected to the RIC, the SONIC's inter- 
nal CAM can perform the address filtering. If a situation 
were such that the RIC would be connected to more than 
the 12 nodes, then either software or an external CAM 
would be necessary to do address filtering. 



RIC AND LERIC REPEATERS FOR ANY APPLICATION 

In this note, a wide variety of applications have been intro- 
duced in a general systems oriented overview. 
A sampling of the breadth of possible hub/repeater applica- 
tions has been presented as well as specifically highlighting 
the importance of network and Hub management as a re- 
quired feature of many repeaters. Discussions of the opera- 
tional characteristics of National's repeater family have 
shown how these repeaters have features that can be effec- 
tively utilized to build systems that address any possible 
Ethernet network repeater product. 
The RIC provides a very feature rich IC platform that en- 
ables building fully managed very high functionality repeat- 
ers of various styles and architectures. 
The LERIC is a very cost effective simple repeater IC that 
should appeal to simple non-managed repeater applications 
that are typically provided for small cost sensitive LAN appli- 
cations. 

With both these devices low end simple Velcro hubs, PC 
Hub Cards, Managed Hubs, Modular Repeaters all can be 
designed very easily and cost efficiently by selecting and 
using either the RIC or LERIC. 
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APPENDIX A. 

IEEE 802.3 HUB MANAGEMENT IMPLEMENTATION 

Management Criteria 

A: Basic control capability Mandatory 

B: Performance monitor Optional 

C: Address tracl<ing capability Optional 
HUB MANAGED OBJECT CLASS 



Object Name 


Object Type 


A 


B 


c 


How Supported By RIC 


How Supported By LERIC 


Hub Attributes 


hubID 


ATTRIBUTE GET 


X 






Software (Note 1) 


Software 


hubGroupCapacity 


ATTRIBUTE GET 


X 






Software 


Software 


groupMap 


ATTRIBUTE GET 


X 






Software 


Software 


hubHealthState 


ATTRIBUTE GET 


X 






Software 


Software 


hubHealthlext 


ATTRIBUTE GET 


X 






Software 


Software 


hubHealthData 


ATTRIBUTE GET 


X 






Software 


Software 


transmitCollislons 


ATTRIBUTE GET 




X 




TXCOLon MngmtBus 


External Logic on ANYXN 


repeaterMJLPs 


ATTRIBUTE GET 




X 




JAB bit on Mngmt Bus 


LEDs 


Hub Actions 


resetHubAction 


ACTION 


X 






Software 


Software 


executeSelflestl Action 


ACTION 


X 






Software 


Software 


executeSelfTest2Action 


ACTION 


X 






Software 


Software 


Hub Notifications 


hubHealth 


NOTIFICATION 


X 






Software 


Software 


hubReset 


NOTIFICATION 


X 






Software 


Software 


groupMapChange 


NOTIFICATION 


X 






Software 


Software 


ResourceTypelD Managed Object Class 


resourceTypelD 




X 






Software 


Software 



Note 1: In the "How Supported..." columns, when Software is noted, this means that the Object is independent of hardware, and is an object that is collected and 
maintained by software or ROM firmware. 

GROUP MANAGED OBJECT CLASS 



Object Name 


Object Type 


A 


B 


C 


How Supported By RIC 


How Supported By LERIC 


Group Attributes 


groupID 


ATTRIBUTE GET 


X 






Software 


Software 


numberOfPorts 


ATTRIBUTE GET 


X 






Software 


Software 
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APPENDIX A. IEEE 802.3 HUB MANAGEMENT IMPLEMENTATION (Continued) 
PORT MANAGED OBJECT CLASS 


Object Name 


Object Type 


A 


B 


c 


How Supported By RIC 


How Supported By LERIC 


Port Attributes 


portID 


ATTRIBUTE GET 


X 






Software 


Software 


portAdminState 


ATTRIBUTE GET 


X 






Ports' Real Time 
Status Register 


Ports' Real Time 
Status Register 


autoPartitionState 


ATTRIBUTE GET 




X 




Ports' Real Time 
Status Register 


Ports' Real Time 
Status Register 


readableFrames 


ATTRIBUTE GET 




X 




# of CLN bit active on 
Mngmt bus 
(no errors) 


— 


readableOctets 


ATTRIBUTE GET 




X 




total # of RBY counts 
on Mngmt bus 


— 


frameCheckSequence- 
Errors 


ATTRIBUTE GET 




X 




CRC bit active on 
Mngmt bus 


— 


alignmentErrors 


ATTRIBUTE GET 




X 




FAE bit active on 
Mngmt bus 


— 


framesTooLong 


ATTRIBUTE GET 




X 




RBY count on Mngmt 
bus 


— 


shortEvents 


ATTRIBUTE GET 




X 




SE bit on Mngmt bus 
(no COL) 


— 


runts 


ATTRIBUTE GET 




X 




RBY count on Mngmt 
bus (no SE) 


— 


collisions 


ATTRIBUTE GET 




X 




Port Event Counters 


External Logic Using 
DPS and LED Drivers 


lateCollisions 


ATTRIBUTE GET 




X 




Event Logging 
Interrupts 


— 


dataRateMismatches 


ATTRIBUTE GET 




X 




ELBER bit on Mngmt 
bus (no COL) 


— 


autoPartitions 


ATTRIBUTE GET 




X 




Event Logging 
Interrupts 


Ports' Real Time 
Status Register 


lastSourceAddress 


ATTRIBUTE GET 






X 


Source address from 
Mngmt bus 


Source Address from 
Ext. Controller 


sourceAddressChanges 


ATTRIBUTE GET 






X 


Software 


Software 


Port Actions 


portAdminControl 


ACTION 


X 






Ports' Real Time 
Status Register 


Ports' Real Time 
Status Register 
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LIFE SUPPORT POLICY 



NATIONAL'S PRODUCTS ARE NOT AUTHORIZED FOR USE AS CRITICAL COMPONENTS IN LIFE SUPPORT 
DEVICES OR SYSTEMS WITHOUT THE EXPRESS WRITTEN APPROVAL OF THE PRESIDENT OF NATIONAL 
SEMICONDUCTOR CORPORATION. As used herein; 

1. Life support devices or systems are devices or 2. A critical component is any component of a life 



systems which, (a) are intended for surgical implant 
into the body, or (b) support or sustain life, and whose 
failure to perform, when properly used in accordance 
with instructions for use provided in the labeling, can 
be reasonably expected to result in a significant injury 
to the user. 



support device or system whose failure to perform can 
be reasonably expected to cause the failure of the life 
support device or system, or to affect its safety or 
effectiveness. 
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